A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on volumes as a hierarchical structure of data containers, such as files and logical units. For example, each “on-disk” file may be implemented as set of data structures, i.e., disk blocks, configured to store information, such as the actual data for the file. These data blocks are organized within a volume block number (vbn) space that is maintained by the file system. The file system may also assign each data block in the file a corresponding “file offset” or file block number (fbn). The file system typically assigns sequences of fbns on a per-file basis, whereas vbns are assigned over a larger volume address space. The file system organizes the data blocks within the vbn space as a “logical volume”; each logical volume may be, although is not necessarily, associated with its own file system.
A known type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block is retrieved (read) from disk into a memory of the storage system and “dirtied” (i.e., updated or modified) with new data, the data block is thereafter stored (written) to a new location on disk to optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL®) file system available from Network Appliance, Inc., Sunnyvale, Calif.
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access data containers stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the storage system by issuing file-based and block-based protocol messages (in the form of packets) to the system over the network.
Most file-level protocols include locking functionality that enables a client to transmit an operation to a software module that acts in conjunction with a file system to implement a lock on either an entire file or a defined subset of a file. Once the lock is granted, only the client owning the lock may perform certain operations (e.g., write operations) directed to the file or subset thereof. Other clients attempting such operations will have these operations denied by the file system. Typically, the file system maintains the current lock state in the memory of the storage system, i.e., in core. That is, if a client acquires a lock, information concerning the lock is typically retained in an in-memory data construct that may be quickly accessed by the file system when determining whether to permit/deny subsequently later requested operations. A noted disadvantage of such a typical implementation arises in the event of a failure of the storage system. If, for example, the storage system suffers an error condition and reinitializes (reboots), all lock state information maintained by the storage system is lost. This forces all clients of the storage system to re-obtain all previously held locks. Should a first client be unsuccessful in re-obtaining a given lock, a second client may write data and/or perform operations to the file in a manner that interferes with potentially partially completed operations initiated by the first client having the original lock. Depending on the types of operations received and the types of operations that were in progress, data corruption and/or data inconsistency may result from the second client's operations. A further noted disadvantage of conventional lock recovery techniques is that the servers must disallow new lock requests for some period of time, which is typically on the order of minutes. During this time period, further disruption of client services is caused by clients being unable to obtain new locks, which may cause timeouts, etc.
Additionally, in environments that support a clustered storage system wherein one “surviving” storage system is capable of “assuming the identity” of a failed storage system, another noted disadvantage is that clients must reestablish locks on the surviving storage system after a failover operation. This reduces the transparency of failover operations and again increases the likelihood of data corruption and/or data inconsistency.